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Title of the Invention 

A process for recording, storing, and displaying discrete trial data. 

Cross Reference to Related Applications 
Not Applicable 

Statement Regarding Federally Sponsored Research or Development 

Not Applicable 

Description of Attached Appendix 
Not Applicable 

Background of the Invention 

The invention relates to a method and process embodied in one or more computer software programs to 
record, store, and display discrete trial therapy data. Discrete trial therapy (or, the discrete trial method) was 
developed by Ivar lovaas at the University of California at Los Angeles. The process of providing discrete trial 
therapy services may be summarized as follows: a person providing services (hereinafter referred to as a Tutor) will 
meet with a person receiving services (hereinafter referred to as Student). The Tutor may select a "curriculum area" 
(e.g., toys, letters, people, animals), a "target" associated with the selected curriculum area (e.g., if the curriculum 
area is "animals," then possible targets may include: dog, cat, mouse, elephant), and a discriminative stimulus (Sd) 
that is relevant to the target (e.g., "point to the _.", "where is the _?", "show me the _."). The Tutor then makes a 
statement (or asks a question) that combines the selected Sd and the target (e.g., "point to the mouse."). Each time 
that a statement is made (or a question is posed) is typically referred to as a "trial." A group of trials may be referred 
to as a "session." The Tutor typically records a Student's response for each trial in the session. Tutors may vary the 
curriculum area, the target, and the Sd from session to session. The Tutor typically uses a paper-based form to 
record session and trial data, which may include: the Student's response to each trial, the date and approximate time 
of the session, the curriculum area, the target, the Sd, the Tutor's name, the Student's name, and any notes relevant 
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to the session. Session data that is recorded on paper may be collected in a binder (or similar repository), and 
analyzed periodically. 

Typically, discrete trial data is captured manually by Tutors, using pencil and paper. Pages of session data 
corresponding to an individual Student may be stored in binders, and aggregated data is typically heuristically 
derived from the raw data. Some data may be entered into a spreadsheet, but this effort is prone to error, and any 
quantitative results beyond basic arithmetic and statistics require sophisticated spreadsheet-programming techniques 
and knowledge. 

The preferred embodiment seeks to obviate the inefficiencies and errors inherent in the manual recording of 
data by using a method that enables discrete data to be recorded directly into a database, whereupon it may be 
aggregated quickly and easily. The benefits to the proposed method are profound. Using a suitable user interface in 
the computer program, session data may be sorted by data, by curriculum area, by Tutor, by Student, and so on with 
a minimum of technical knowledge on the part of the user of the invention. Database queries may be filtered 
according to user-selected variables and displayed quickly and easily. Displayed results may be printed, or exported 
to a file. Weeks, months, and years of a Student's session data may be electronically archived with a few computer 
commands, helping to ensure compliance with any legal requirements to store Student data until a Student becomes 
a certain age. 

There is an invention (#6,537,073, issued Mar. 25, 2003) that enables a use to deliver content to a learning 
disabled person, but the invention focuses on delivering content to a single user instead of enabling data recording 
for multiple Students. The inventor for this current application knows of no existing method, embodied in one or 
more computer software programs that enables a person or persons providing discrete trial therapy services to 
record, store, and display discrete trial data. 



Brief Summary of the Invention 

The present invention seeks to obviate the disadvantages and limitations of the described prior 
arrangements. In particular, the invention comprises one or more computer programs that facilitate the recording, 
storing and displaying of discrete trial data. 
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Discrete trial therapy services are typically delivered by privately owned companies (i.e., an agency) to its 
clientele of Students, or delivered through school systems. Students may visit an agency or a school to receive 
services, or a Tutor may visit the Student to provide services. For large numbers of Students, it is unwieldy and 
inefficient to monitor and manage session data over time. 

In the preferred embodiment, a person who is using the invention uses one or more computer programs to 
create and modify user accounts for every Tutor who provides services to Students and for every for Student who 
receives services. A person may also use the invention to create and modify a library of curriculum areas, targets, 
and Sd's that may be used by a Tutor when providing services to a Student, and to record trial data on the computer. 

Another aspect of the invention is a method for recording discrete trial data on a mobile computer. A Tutor 
uses this aspect of the invention to record session data while away from the computer in which the curriculum areas, 
targets, Sd's, accounts, and so on are stored. 

Because the data recording may be conducted on a mobile device, there is an additional aspect of the 
invention that enables different computer programs of the invention to share and to exchange database contents, 
despite having the databases reside on computers using different operating systems and platforms. This enables an 
agency, or other group or individual that provides services, to record data on multiple mobile devices, and aggregate 
collected data into a database on a single computer. 

Another aspect of the invention is a method for querying the aggregated data to display data that enable an 
agency, group, or individual that is providing services to provide more effective treatment and therapy. 
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Brief Description of the Drawings 

The drawings constitute a part of this specification and include exemplary embodiments to the invention, 
which may be embodied in various forms. It is to be understood that in some instances various aspects of the 
invention may be shown exaggerated or enlarged to facilitate an understanding of the invention. 

FIG. 1 is a general overview of a discrete trial data recording, storage, and data display system. 

FIG. 2 is a general overview of a system comprising a computer system that may be associated with a 
communications network, with mobile devices, with both, or with neither. 

FIG. 3 is a flow diagram illustrating the procedure for adding a user account. 

FIG. 4 is an overview of a graphical user interface for displaying user accounts. 

FIG. 5 is a flow diagram illustrating the procedure for modifying an existing user account. 

FIG. 6 is an overview of a graphical user interface for adding a new curriculum area, with associated targets and 
associated Sd's. 

FIG. 7 is an overview of a graphical user interface for adding new targets and Sd's to an existing curriculum area. 

FIG. 8 is a flow diagram illustrating the procedure for associating a subset of curriculum areas to Student account(s). 

FIG. 9 is a flow diagram illustrating the procedure for associating a subset of Student accounts to curriculum area(s). 

FIG. 10 is a flow diagram illustrating the procedure for recording discrete trial data. 

FIG. 11 is an overview of a graphical user interface for recording discrete trial response data. 

FIG. 12 is a flow diagram illustrating the procedure for choosing curriculum area, target, and Sd parameters. 

FIG. 13 is a flow diagram illustrating the procedure for displaying data. 

FIG. 14 is a flow diagram illustrating the procedure for synchronizing data between computer 210 and mobile 
device 240. 
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Detailed Description of the Preferred Embodiments 

Detailed descriptions of the preferred embodiment are provided herein. It is to be understood, however, that 
the present invention may be embodied in various forms. Therefore, specific details disclosed herein are not to be 
interpreted as limiting, but rather as a basis for the claims and as a representative basis for teaching one skilled in the 
art to employ the present invention in virtually any appropriately detailed system, structure or manner. 

FIG. 1 is a general overview of a discrete trial data recording, storage, and display system. In one 
embodiment, database 1 1 0 stores the information necessary to identify the individual people who are involved in the 
delivery of discrete trial therapy services. This may include the Students who receive the therapy services and Tutors 
who deliver therapy services to Students. 

In one embodiment, database 120 stores the Content that may be used during the delivery of therapy 
services. The Content may be a list of curriculum areas, lists of targets related to individual curriculum areas, and 
lists of Sd's related to individual curriculum areas. In the preferred embodiment, a user of the invention may create 
new Content and modify existing Content as needed. 

In one embodiment, block 1 30 is a process in which the Tutor records data that may be related to the 
Student and to some Content. For example, the Tutor may record: the Tutor's own name, responses a Student may 
make with respect to specific content, the time that responses were recorded, the date on which responses were 
recorded, performance metrics (e.g., percent correct), textual notes, graphical notes, the specific Content that was 
used during the delivery of therapy services, and so on. As the data is recorded, using the procedure in block 130, it 
may be stored in database 140. 

Database 140 is a repository of data recorded as a result of the procedure in block 130. Data in database 
130 may contain references to accounts in database 1 10 and Content in database 120. Using the data in database 
140, the user of the invention may display data using a process in block 150. 

Block 150 is a process for displaying data from database 140. The displayed data may be results from 
predefined queries to the database, they may be statistical data generated by current or previous queries, or they may 
be results to queries that allow for the user of the invention to filter data according to user-selected parameters. For 
example, the use:'r may display progress results for one or more Students, organize data according to different 
criteria, display raw data, and display cumulative time spent in delivering therapy services. 
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FIG. 2 is a general overview of a system comprising a computer system that may be associated with a 
communications network, with mobile devices, with both, or with neither. 

Computer 210 includes conventional computer electronics including a motherboard containing the 
processor and an associated chip set, a communications bus, a user input device (e.g., mouse), a display device (e.g., 
a screen or monitor), a power supply and various interface and drive electronics. In one embodiment, computer 210 
is a processor configured to perform specific tasks. The computer 210 may have a configuration based on Intel 
Corporation's family of microprocessors, such as the Pentium family and Microsoft Corporation's Windows 
operating systems such as Windows 98, Windows Millennium Edition, Windows 2000, or Windows XP. 

It is contemplated, however, that the computer 210 can be implemented with a wide range of computer 
platforms using conventional general purpose single chip or multichip microprocessors, digital signal processors, 
embedded microprocessors, microcontrollers and the like. It is also contemplated that the computer 210 may be 
implemented with a wide range of operating systems such as Unix, Linux, Microsoft DOS, Microsoft CE, 
Macintosh OS, OS/2 and the like. 

In one embodiment, the system comprised of database 1 10, database 120, block 130, database 140, and 
block 150 may be installed on only computer 21 0. In another embodiment, any combination of databases 1 10, 
database 120, block 130, database 140, and block 150 maybe installed on any combination of computer 210, 
networked computer 220, and mobile device 240. 

Computer 220 may be substantially similar to computer 210 with regard to hardware and operating system. 
In one embodiment, Computer 220 and computer 210 may be connected by a communications network 230 such as 
a local area network (LAN), a wide area network (WAN), TCP/IP, 802.1 1, Ultra Wide Band, Bluetooth, and so on, 
that provide continually available network connectivity between computer 210 and computer 220. 

Computer 240 may be a computer device that may not have continually available network connectivity 
with computer 210, and instead exchanges data with computer 210 periodically. Computer 240 may need to store 
data in a form and format that may be consistent with the form and format of data stored on computer 210. It is 
contemplated that mobile device 240 may be implemented with a wide range of platforms designed for mobile 
computing, using conventional devices such as handheld computers, data-enabled mobile phones, smart phones, 
data-enabled watches, pagers, Blackberry-type devices, and so on, running operating systems such as the Palm OS, 
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Windows Pocket PC, Windows XP Tablet PC Edition, Symbian, Linux, and so on. Data may be exchanged between 
mobile device 240 and computer 210 via a data exchange procedure in block 250. The procedure in block 250 may 
be specific to the configuration of the mobile device 240. For example, if the mobile device 240 is a Palm OS 
compatible device, data between mobile device 240 and compute 210 may be exchanged via infrared beaming, 
Bluetooth, USB cable, or an SDIO card,. Regardless of the type of mobile device 240, in one embodiment, block 
250 must enable data to be exchanged between mobile device 240 and computer 210. 

In one embodiment, database 1 10, database 120 and database 140 may reside on a hard drive of computer 
210, and block 130 may be an input method enabled on computer 220 that allows data from database 1 10 and 
database 120 to be visible on computer 220 so that data may be recorded via block 130, the results of which may be 
stored on computer 2 1 0. In another embodiment, the system on computer 210 may be a multi-user application (such 
as on the CYTRIX system) so that all data resides on computer 210. In another embodiment, database 1 10, database 
120, and input method 130 are copied periodically to computer 220 by network 230, so that if computer 220 creates 
a database 140, then database 140 may be copied back to computer 210. 

In the preferred embodiment, modifications and updates to database 1 10, database 120, and database 140 
are enabled from only computer, 210, although copies or subsets of database 1 10, database 120, and database 140 
may exist on computer 220, on mobile computer 240, or both. 

In another embodiment, copies of database 1 10, database 120 and database 140 may be sent to mobile 
device 240 during data exchange 250. Remote device 240 may be enabled to store subsets of databases 1 10 and 120 
and has installed on it data input method 130. As data is collected on mobile device 240, performance data (data 
which will be later added to database 140) is created. The next time computer 210 and mobile device 240 exchange 
data via block 250, updated copies of database 1 10, database 120 and database 140 may be sent from computer 210 
to mobile device 240 and a database 140 may be sent from mobile device 240 to computer 210 where it is 
aggregated with previous data. 

In another embodiment, block 1 30 may be enabled on both computer 210 and mobile device 240, on both 
computer 210 and computer 220, or on all of computer 210, computer 220, and mobile device 240. 

In one embodiment, database 140 may reside on the hard drive of computer 210 and the display procedure 
in block 1 50 may be enabled on computer 2 1 0. In another embodiment, the display procedure in block 1 50 may be 
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enabled on computer 210, which may query database 140 on computer 210 over network 230. In another 
embodiment, the display procedure in block 150 may be enabled on computer 210, which may query a copy of 
database 140 that resides on the hard drive of computer 220. 

FIG. 3 is a flow diagram illustrating the procedure for adding a user account. In one embodiment, there 
may be different types of accounts for different types of people for whom data is stored. A person using the 
invention would initiate the process at the START block 3 10 by using means typically available to a computer user: 
the computer user could click a button, choose a command from a menu, press a combination of keyboard keys, and 
so on. 

At block 320 the computer user may be presented with a method for inputting data into a computer, (e.g., 
an onscreen form) that may present the user with options for providing data relevant to the user account. The input 
method may contain any combinations of text fields to receive text, pulldown menus to choose from short lists of 
predetermined data options (e.g. months of the year), radio buttons to force the user to choose between or among 
sets of options (e.g. male or female), check boxes to indicate whether a choice is selected or not selected, and so on. 
The fields that are provided in block 320 may be different for different types of users. Block 320 may contain certain 
fields if the computer user is seeking to create a Tutor account, and block 320 may contain certain other fields if the 
user is seeking to create a Student account. 

At block 330, the user of the invention provides data into block 320. The data corresponds to the person for 
whom the account is being created. In one embodiment, the computer user may be required to provide certain data to 
be able to create the account, whereas some data may be optionally provided. In one embodiment, the user of the 
invention may later modify some data that may have been supplied in block 330, and in other embodiments of the 
invention, the user may not modify any of the data that may have been supplied in block 330. 

Proceeding to block 340, the user of the invention may elect to save and store the data supplied in block 
330, or discard the data supplied in block 330. If the user elects to discard the data supplied in block 330, no new 
user account is created, no new database record is created, the new form closes (block 370), and the user of the 
invention proceeds to block 380. The user of the invention may elect to save the data supplied in block 330, with the 
intention of creating a new user account in a database. If the user of the invention elects to save the data and create 
the account, the process proceeds to block 390. 
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In block 390, the process evaluates the data supplied in block 330 to determine whether the data that is 
required in block 330 is present. In one embodiment, it may be required to provide a first and last name for the user 
for whom the account is being created, in another embodiment, it may be required to provide a first name, a last 
name, and an alphanumeric username. Further, the data requirements may be different for different types of 
accounts. In one embodiment, the same data requirement may be applied to all accounts irrespective of the account 
type. In another embodiment, there may be one set of data requirements for one account type and a different set of 
data requirements for other account types. If the user of the invention supplies data that meets the data requirements 
for the type of account being created, the process proceeds to block 350. If the data requirements are not met at the 
time the user attempts to save the data and create the account, the user is returned to block 330 to provide the 
remainder of the required data. 

In block 350, the process evaluates the data supplied in block 330 to determine whether the data meets 
uniqueness criteria determined in the embodiment. In one embodiment, uniqueness may be achieved when the 
computer user seeking to create the new account provides in block 330 an alphanumeric name - assuming the 
embodiment provides this field in block 320 - for the new account that is not identical to an alphanumerical name 
for an account that has been previously created. This is not unlike AOL not allowing any two people to have the 
same email address, or a telephone company not allowing two different cell phones to have the same phone number. 
In another embodiment, uniqueness may be achieved by ensuring that the combination of the first and last names of 
the user account is not identical to the combination of the first and last name of an existing user. Further, the 
uniqueness requirements may be different for different types of accounts. In one embodiment, the uniqueness 
requirement may be applied to all accounts irrespective of the account type. In another embodiment, there may be a 
set of uniqueness requirements for one account type and a different set of requirements for other account types. If 
the user of the invention supplies sufficient data to meet the uniqueness requirements for the type of account being 
created, the process proceeds to block 360. If the uniqueness requirements are not met, the user is returned to block 
330 to edit or provide data to satisfy the uniqueness requirements defined in the embodiment. 

In block 360, because sufficient data have been supplied to meet the requirement criteria (block 390) for 
the type of account being created, and because the account meets the uniqueness criteria (block 350) for the type of 
account being created, the data that the user of the invention supplied in block 330 may be saved and stored in 
database 110. 

The process ends at block 380, whether a new account was created or not. 
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FIG. 4 is an overview of a graphical user interface for displaying user accounts. In one embodiment, all 
types of accounts may be displayed within a single window. In another embodiment, different types of accounts may 
occupy different windows, which may occupy different screens in the computer programs. 

In one embodiment, block 410 may be a scrolling list of the user accounts that have been previously 
created, with each row in the scrolling list corresponding to a single account. 

In one embodiment, additional data corresponding to the account may be displayed in the row. For 
example, if the input method in block 320 provides a field for a telephone number, and the user of the invention 
supplies that information, one embodiment of the invention may list the phone number in the row in list 410. 

Block 420 is a mechanism to enable the user of the invention to create a new account. The mechanism may 
be any combination of: a button that the user clicks with a mouse, a command that the user of the invention invokes 
by pressing one or more keyboard keys, a command that is selected from a menu, and so on. When the user of the 
invention elects to add a new account, the process described in FIG. 3 is followed. 

Block 430 is a mechanism to enable the user of the invention to modify an existing account. That is, the 
user of the invention may edit data that already exists in an account, or may add new data that was not previously 
when the account was originally created. The mechanism in block 430 may be a button that the user of the invention 
clicks with a mouse, a command that the user of the invention invokes by pressing one or more keyboard keys, a 
command that is selected from a menu, and so on. In one embodiment, the user of the invention would select an 
account, then invoke the process to modify the account. When the user elects to modify an existing account, the 
process described in FIG. 5 is followed. 

FIG. 5 is a flow diagram illustrating the procedure for modifying an existing user account. Block 510 starts 
the procedure. In block 520, the user of the invention may select an account from the list described in block 410. 
After the user of the invention selects an account to modify, the user of the invention may proceed to block 530 by 
using a computer mouse to click a button, to choose an item from a menu, by pressing a combination of computer 
keyboard keys, and so on. Block 530 may be similar to block 320. Block 540 is an input method that the user of the 
invention may use to modify existing data or add new data for a user - block 540 may be similar to block 330. 

Proceeding to block 550, the user of the invention may elect to save and store the modified information 
and/or the newly provided information. While the user of the invention is modifying data in the account, the original 
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account data may not be modified until the user elects to save the modifications. If the user of the invention does not 
elect to save and store the information, the newly added data is discarded in block 570, the input method closes in 
block 580, and the procedure ends in block 590. Any data that was provided in block 540 may be discarded so that 
the account being modified remains unchanged at block 590. If the user of the invention elect to save and store the 
information, the account information is updated in block 560, the data is saved to database 1 10, the input method 
closes in block 580, and the procedure ends in block 590. 

FIG. 6 is an overview of a graphical user interface for adding a new curriculum area, with associated 
targets and associated Sd's. In the preferred embodiment, each curriculum area that is created has associated with it 
a set of Sd's and a set of targets. In the preferred embodiment, sets of Sd's and sets Targets associated with one 
curriculum area are not associated with any other curriculum area. In another embodiment there may be a set of 
curriculum areas, a set of Sd's, and a set of targets that may have no defined association with each other. 

In one embodiment, the user of the invention supplies in block 605 a name for the curriculum area. The 
name may contain letters, numbers, and symbols. There may be a limit to the number of characters a user of the 
invention can supply in block 605. 

In one embodiment, the user of the invention supplies in block 610 a mastery level for the curriculum area. 
In one embodiment, a mastery level may be a single number, representing a percent between 0 and 100; this number 
may be used to determine if the percent correct recorded during a session (see FIG. 10) is greater than or equal to the 
percent correct assigned to the mastery level. In another embodiment, the mastery level may be a series of numbers, 
each corresponding to a different gradation of success demonstrated by the Student. 

Block 615 shows, in one embodiment, a list of the targets that have been created. The list of targets that are 
created are, in this embodiment, associated with the curriculum area named in block 605. 

A new target may be created by invoking block 625, which may be invoked by clicking a button, selecting 
a menu item, pressing a combination of keyboard keys, and so on. When block 625 is invoked, an input method 
(e.g., a small onscreen window) may appear that enables the user to provide in the name of the new target. In the 
preferred embodiment, the user is asked to indicate whether to save or discard the name of the new target. In the 
preferred embodiment, no two targets associated with a single curriculum area may have the same name. That is, a 
user may not create a new target that has the same name as existing target. 
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A target that appears in the list may be renamed by selecting the target and invoking block 630, which may 
be invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so on. When a 
target is selected from the list, and block 630 is invoked, an input method (e.g., a small onscreen window) may 
appear that displays the target name in an editable text field. The user may elect to change the name of the target. In 
the preferred embodiment, the user is asked to indicate whether to save or discard the changed name. In the 
preferred embodiment, no two targets associated with a single curriculum area may have the same name. That is, a 
user may not rename an existing target so that it has the same name as another existing target. 

A target that appears in the list may be deleted from the list by selecting the target and invoking block 635, 
which may be invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so 
on. When a target is selected from the list, and block 635 is invoked, the target is removed from the target list. 

Block 620 shows, in one embodiment, a list of the Sd's that have been created. The list of Sd's that are 
created are, in this embodiment, associated with the curriculum area named in block 605. 

A new Sd may be created by invoking block 640, which may be invoked by clicking a button, selecting a 
menu item, pressing a combination of keyboard keys, and so on. When block 640 is invoked, an input method (e.g., 
a small onscreen window) may appear that enables the user to type in the name of the new Sd. In the preferred 
embodiment, the user is asked to indicate whether to save or discard the name of the new Sd. In the preferred 
embodiment, no two Sd's associated with a single curriculum area may have the same name. That is, a user may not 
create a new Sd that has the same name as existing Sd. 

An Sd that appears in the list may be renamed by selecting the Sd and invoking block 645, which may be 
invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so on. When an 
Sd is selected from the list, and block 645 is invoked, an input method (e.g., a small onscreen window) may appear 
that displays the Sd name in an editable text field. The user may elect to change the name of the Sd. In the preferred 
embodiment, the user is asked to indicate whether to save or discard the changed name. In the preferred 
embodiment, no two Sd's associated with a single curriculum area may have the same name. That is, a user may not 
rename an existing Sd so that it has the same name as another existing Sd. 
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An Sd that appears in the list may be deleted from the list by selecting the Sd and invoking block 650, 
which may be invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so 
on. When a target is selected from the list, and block 650 is invoked, the Sd is removed from the Sd list. 

The user of the invention may elect to save the curriculum area name, any mastery level data that may have 
been provided, any targets that may have been provided, and any Sd's that may have been provided. In one 
embodiment, the aforementioned data is not saved to database 120 until and unless the user invokes block 655, 
which may be invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so 
on. In the preferred embodiment, prior to invoking block 655, all the data that was supplied would reside in the 
computer's random access memory (RAM), or in a temporary file. When the user of the invention elects to save the 
aforementioned data, the data are transferred from RAM (or the temporary file) to database 140. In one embodiment, 
users may not create a new curriculum area whose name is identical to the name of an existing curriculum area. 

The user may elect to discard the curriculum area name, any mastery level data that may have been added, 
any targets that may have been added, and any Sd's that may have been added by invoking block 660, which may be 
invoked by clicking a button, selecting a menu item, pressing a combination of keyboard keys, and so on. If the user 
of the invention elects to discard the data, no new information is added to database 140 and the form for creating the 
curriculum area, the targets, the Sd's, and the mastery level may be closed. 

FIG. 7 is an overview of a graphical user interface for adding new targets and Sd's to an existing 
curriculum area. Many of the graphical user interface elements present in FIG. 7 are present in FIG. 6 and have the 
same functionality as described in FIG 6. Blocks 615 through 660 in FIG. 7 have identical functionality to the same- 
numbered blocks as in FIG. 6. The blocks that are new to FIG. 7 are as follows: block 705 displays the name of the 
existing curriculum area. In the preferred embodiment, because the user of the invention is modifying an existing 
curriculum area, via this graphical user interface, it is assumed that the curriculum area already has a name. In the 
preferred embodiment, the name is not editable, but rather displayed for reference. In another embodiment, names of 
curriculum areas may be edited or otherwise modified. 

Block 710 may provides the user of the invention an opportunity to add or modify the mastery level, as 
defined in FIG 6. In the preferred embodiment, block 715 displays a list of targets that were previously created using 
the graphical user interface described in FIG 6. In the preferred embodiment, block 720 displays a list of targets that 
were previously created using the graphical user interface described in FIG 6. 
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FIG. 8 is a flow diagram illustrating the procedure for associating a subset of curriculum areas to Student 
account(s). Database 1 1 0 contains information about people involved in discrete trial therapy services, and may 
include Student accounts. Database 120 contains Content that may be used during discrete trial therapy, and may 
contain database records for curriculum areas, targets and Sd's. In one embodiment, where a copy of database 120 is 
sent to a mobile device 240, the user of the invention may wish to send a subset of database 120 rather than a copy 
of the entire database. FIG. 8 describes the procedure for identifying a subset of Content that is assigned to a specific 
Student account. 

The user of the invention starts at block 805. In FIG. 4, there is a list of user accounts, some or all of which 
may be Student accounts. In one embodiment, the user of the invention may use a typical mouse input device or a 
keyboard connected to computer 210 to select a single Student account in block 810. In another embodiment, the 
user of the invention may select more than one Student account. Proceeding to block 815, the user of the invention 
may see a list of the currently defined curriculum areas in database 120. The list may appear in an onscreen scrolling 
window in block 815. 

In block 820, the user of the invention may close the window that displays the list of curriculum areas in 
block 815. If the user of the invention closes the window, proceed to block 850. 

Proceeding to block 825, where, in one embodiment, the user of the invention selects a single curriculum 
area. In another embodiment, the user of the invention may select more than one curriculum area. In one 
embodiment, there may be a user interface mechanism in block 830 that enables the user of the invention to identify 
whether the curriculum areas selected in block 825 are assigned or unassigned to the Student(s) selected in block 
810. This user interface mechanism may take the form of a check box, where, in one embodiment, curriculum areas 
that are checked are associated with the selected Student Accounts and those curriculum areas whose check boxes 
are not checked are not associated with the selected Student account. When the user of the invention finishes 
identifying the associations between the curriculum area(s) and the selected Student(s), the window in block 820 
may be closed, and the procedure continue to block 850. 

In the preferred embodiment, the user of the invention may associate a subset of the curriculum areas with 
Students. In the preferred embodiment, if a curriculum area is not assigned to a Student, none of the targets or Sd's 
associated with the Curriculum Area are associated with the Student. In another embodiment, the user of the 
invention may be able to associate individual Sd's and individual targets with selected Students. 
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FIG. 9 is a flow diagram illustrating the procedure for associating a subset of Student accounts to 
curriculum area(s). Database 1 10 contains information about people involved in discrete trial therapy services, and 
may include Student accounts. Database 120 contains Content that may be used during discrete trial therapy, and 
may contain database records for curriculum areas. In one embodiment, where a copy of database 120 is sent to a 
mobile device 240, the user of the invention may wish to send a subset of database 120 rather than a copy of the 
entire database. FIG. 9 describes the procedure for identifying a subset of Students that are assigned to a specific 
curriculum area. 

The user of the invention starts at block 905. In FIG. 6, the user of the invention creates new curriculum 
areas, which, in one embodiment, may be listed in a scrolling window, in a manner not unlike how accounts are 
listed in FIG. 4. In one embodiment, the user of the invention may use a typical mouse input device or a keyboard 
connected to computer 2 10 to select a curriculum area in block 910. In another embodiment, the user of the 
invention may select more than one curriculum area. Proceeding to block 915, the user of the invention may see a 
list of the currently defined curriculum areas in database 120. The list may appear in an onscreen scrolling window 
in block 915. 

In block 920, the user of the invention may close the window that displays the list of Students in block 915. 
If the user of the invention closes the window, proceed to block 950. 

Proceeding to block 925, where in one embodiment, the user of the invention selects a single Student, 
account. In another embodiment, the user of the invention may select more than one Student account. In one 
embodiment, there may be a user interface mechanism in block 930 that enables the user of the invention to identify 
whether the Student account(s) selected in block 91 5 are assigned or unassigned to curriculum area(s) selected in 
block 910. This user interface mechanism may take the form of a check box, where, in one embodiment, Student 
accounts that are checked are associated with the selected curriculum area and those Student accounts whose check 
boxes are not checked are not associated with the selected curriculum area. When the user of the invention finishes 
identifying the associations between the selected curriculum area(s) and the Student account(s), the window in block 
920 may be closed, and the procedure continue to block 950. 

In the preferred embodiment, the user of the invention may associate a subset of the Student accounts with 
curriculum areas. In the preferred embodiment, if a curriculum area is not assigned to a Student, none of the targets 
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or Sd's associated with the Curriculum Area are associated with the Student. In another embodiment, the user of the 
invention may be able to associate individual Sd's and individual targets with selected Students. 

FIG. 10 is a flow diagram illustrating the procedure for recording discrete trial data. In one embodiment, 
discrete trial data may be recorded on mobile device 240, on computer 210, or on computer 220. Begin at block 
1010, which may be an onscreen form as described in FIG. 1 1 . Typically, a Tutor is responsible for recording 
discrete trial data. So, in block 1 0 1 5, in one embodiment, the Tutor may identify the Student who is about to receive 
therapy service by selecting that Student's name, or identifier, from a list of available names or identifiers from 
database 1 10. If a test in block 1020 determines the list in block 1015 is empty, any future recorded results may not 
be assigned to any Student and so the procedure may proceed to its conclusion at block 1075. If the list is nonempty, 
the Tutor may select a Student name from list 1015 and proceed to block 1025. 

In block 1025, the Tutor may identify himself or herself by selecting his or her name, or account identifier, 
from an onscreen list whose contents may be populated by a subset of database 1 10. If a test in block 1030 
determines that the list in block 1 025 is empty, any future recorded results may not be assigned to any Tutor and so 
the procedure may proceed to its conclusion at block 1075. If the list is nonempty, the Tutor may select his or her 
name from the list and proceed to block 1035. 

At block 1035 the Tutor may proceed with data recording. In one embodiment, this procedure is a loop 
wherein a Tutor may continue to provide service to the same Student identified in block 1025 without having to re- 
choose the name or identifier of the Student. If the Tutor elects not to continue at block 1035, the procedure may 
terminate at block 1075. If the Tutor elects to continue at block 1035, the procedure continues to block 1040. 

In block 1040, the Tutor selects the Content which will be used during the delivery of therapy services. 
This may include selecting a curriculum area, one or more targets, and an Sd from database 120. Block 1040 is 
detailed in FIG. 12. Proceeding to block 1 045, the Tutor selects a type of therapy. One type of therapy may allow for 
the use of targets as distractors; another type of therapy may not allow for the use of distractors. Proceeding to block 
1050, the Tutor may record Student response data; block 1050 is detailed in FIG. 11. 

After a Tutor records response data in block 1050, the Tutor may decide in block 1060 whether to save the 
data recorded in block 1 050, or whether to discard it. If the Tutor elects in block 1070 to save the data, a database 
record may be written to database 140, which may include: the Tutor account identified in block 1015, the Student 
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account identified in block 1025, the Content selected in block 1040, the therapy type selected in block 1045, the 
response data recorded in block 1050, and the time and date that data was recorded. The system time and date for the 
computer on which block 1 30 is run may be affixed to data recorded in block 1 050. After the recorded data is 
recorded in block 170, the procedure returns to block 1035, where the Tutor may elect to continue to record new 
data or temporarily conclude the delivery of therapy services at block 1075. 

If the If the Tutor elects not to save the data in block 1065, no database record is written and the procedure 
continues to block 1035, where the Tutor may elect to continue to record new data or temporarily conclude the 
delivery of therapy services at block 1075. Data that is recorded in block 1050 and discarded in block 1065 may not 
be added to database 140. 

FIG. 1 1 is an overview of a graphical user interface for recording discrete trial response data. In the 
preferred embodiment, Tutors may: identify the Student in block 1015, identify themselves in block 1025, select 
Content in block 1040,and select a therapy type in block 1045, prior to recording discrete trial data in block 1050. 
These selections may be displayed in block 1110, for reference to assist the Tutor. 

Block 1 120 may consist of four parts: there may be a list of the targets chosen in block 1040 (shown on the 
left); there may be an input method for capturing the responses, which may be Correct, Incorrect, Non-responsive, 
and Prompted (an array of C, I, N, and P shown in the middle); there may be a display of metrics (shown on the 
right); and there may be a tracking mechanism that increments how many responses have been recorded (at the 
bottom of block 1 120). The metrics may display the percent correct of each target. 

The input method displayed in block 1 120 may be an array of buttons, with each row of the array 
corresponding to a target and each column of the array corresponding to a response of either C (correct), I 
(incorrect), N (non-responsive), and P (prompted). The Tutor may click any button (or use a similar input method) in 
the array to associate a response type to a target. Each time a response is recorded, the tracking mechanism indicates 
that a responses has been recorded. In one embodiment, a row of empty rectangles indicates the maximum number 
of possible responses, and each time a response is recorded, the left-most empty rectangle becomes filled. In one 
embodiment, there is a small diamond that may be positioned over any of the black-filled rectangles or over the left- 
most white-filled rectangle. If the diamond is positioned above the Nth black rectangle, the array entry 
corresponding to the Nth response is displayed. A Tutor may change a previously recorded response. If the diamond 
is positioned over the leftmost white-filled rectangle, then the array of C, I, N, and P serve as an input method to 
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record the Nth response. The Tutor may click either triangle to move the diamond laterally. The metrics on the right 
side of block 1 120 may measure the percent of recorded responses that a Correct for the corresponding target. 

The metrics in block 1 130 may display the percent of all responses that are Correct, as recorded in block 
1 120. and it may display the mastery level, if it is defined in block 610. 

In one embodiment, there is Notes button 1 150 than enables an input method that a Tutor may use to record 
notes that become associated with the current set of responses. 

The done button in block 1 1 60 may enable a Tutor to temporarily conclude recording responses and save 
the recorded responses, as described in block 1070. 

The cancel button in block 1 1 70 may enable a Tutor to temporarily conclude recording responses and 
discard the recorded responses, as described in block 1065. 

FIG. 12 is a flow diagram illustrating the procedure for choosing curriculum area, target, and Sd 
parameters. Database 120 contains a library of the curriculum areas, targets and Sd's used in the delivery of discrete 
trial therapy services. In one embodiment, before recording Student responses, a Tutor may select a curriculum area, 
a target, and an Sd, according to FIG. 12, by beginning at block 1210. 

In the preferred embodiment, there is a set of Sd's and a set of targets associated in the database with each 
curriculum area. So, in one embodiment, it may be necessary to display a list of curriculum areas from database 120, 
in a list in block 1215, which, after one is selected, will determine which set of Sd's and which set of targets are 
available to choose from later. The list of curriculum areas may appear in one of several different ways onscreen; for 
example, a list of the curriculum areas may appear in a popup menu, the list may appear in a scrolling window, on so 
on.. The list of curriculum areas may be empty or nonempty. In the preferred embodiment, if a test in block 1220 
determines that the list of curriculum areas is empty, then no curriculum area is available, and hence no 
corresponding set of Sd's and no corresponding set of targets may be available, and there may be no Content about 
which to record data. So, if the list of curriculum areas is empty, proceed to block 1260. 

If a test in block 1220 determines that the list of curriculum areas in block 1215 is nonempty, then the user 
of the invention may choose a curriculum area in block 1225. In the preferred embodiment, the list of targets that are 
displayed in block 1230 may be dependent on the curriculum area that was chosen in block 1225. If a test in block 
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1235 determines that the list of targets (corresponding to the Curriculum Area selected in block 1225) is empty, then 
the user of the invention may display the list of curriculum areas again in block 1215. If a test in block 1235 
determines that the list of targets in block 1230 is nonempty, the user of the invention may select one or more targets 
in block 1240 and proceed to display a list of Sd's in block 1245. 

In the preferred embodiment, the list of Sd's that are displayed in block 1240 may be dependent on the 
curriculum area that was chosen in block 1225. If a test in block 1250 determines that the list of Sd's (corresponding 
to the Curriculum Area selected in block 1225) is empty, then the user of the invention may display the list of 
curriculum areas again in block 1215. If a test in block 1250 determines that the list of Sd's in block 1245 is 
nonempty, the user of the invention may select one or more Sd's in block 1255 and proceed to block 1260. 

In another embodiment, the user may select an Sd before selecting one or more targets. 

FIG. 13 is a flow diagram illustrating the procedure for displaying data. Database 140 may contain data 
regarding Student responses; the time and duration that Students received discrete trial therapy services; the time 
and duration that Tutors provide discrete trial therapy services to Students; system times for computer 220, computer 
210, and/or mobile device 240; notes that Tutors may have recorded; the curriculum areas, targets, and Sd's used in 
the delivery of discrete trial therapy services; and so on. People may be interested in the data contained in database 
140, and may want to have certain data presented in certain ways to facilitate analysis of the data. People may wish 
to display data stored in database 140 using the procedure described in FIG. 8. 

The user of the invention starts at block 1310 by initiating a request to see a list of available report types in 
block 1320. This request may be conveyed to the computer by using a mouse, by pressing a sequence or 
combination of keys on a computer keyboard, and so on. One report type may be distinguished from another by the 
database query that is used to generate the report or the type of data that is displayed in the report. For example, a 
report that displays the amount of time a Student has received discrete trial therapy services may be a different 
report type than a report that displays a subset of raw data from database 140. There may be any number of report 
types available in the embodiment. 

In block 1320, the user may see a list of different report types. At block 1330, block 1345, block 1360, and 
block 1380, the user of the invention may elect to end the procedure and proceed to block 1390. In block 1340, the 
user of the invention may choose a report type. In block 1350, the user of the invention may choose report 
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parameters. These parameters may affect the database query that may build the report; examples of parameters 
include, choosing a specific data range, filtering out data for one or more Student accounts, and filtering out data for 
one or more Tutor account. 

After the parameters are chosen, the user of the invention may see the results displayed in block 1380. The 
results may be based on the report type selected in block 1340 and the parameters chosen in block 1350.The data 
may be displayed on a computer screen or may be sent to a printer. 

FIG. 14 is a flow diagram illustrating the procedure for synchronizing data between computer 2 10 and 
mobile device 240. In the preferred embodiment, a mobile device 240 is assigned to a Student, who may be uniquely 
defined in database 1 1 0. The procedure for recording data (via FIG. 10) may reside on mobile device 240. In this 
embodiment, it is necessary to transfer copies of subsets of database 1 10 and 120 to mobile device 240. To enable 
this embodiment, there must be a procedure for exchanging data between computer 210 and mobile device 240. In 
the preferred embodiment, exchanging data between a mobile device 240 may be facilitated by developing a 
software program that uses an open Application Programming Interface (API) for a specific type of device 240. For 
example, if mobile device 240 is a Palm OS handheld, then data may be exchanged via the Palm OS HotSync 
application; more specifically, each application that is installed on a Palm device and exchanges data with a 
computer must have a HotSync conduit written for the specific application enabling it to exchange data. 

After the procedure to exchange data begins in block 1410, a test is conducted in block 1420. The test may 
determine whether data may be exchanged between computer 210 and mobile device 240. The criteria for the test 
may include: determining whether there is a computer program present on computer 210 which may exchange data 
with the mobile device 240; determining whether the data stored on mobile device 240 has a compatible data 
structure as that of database 140; determining whether an identifier on mobile device 240 has a matching identifier 
on computer 210, and so on. If all of the criteria in the embodiment are not met in block 1420 then the procedure for 
exchanging data is terminated and the procedure continues to block 1450. 

If all the criteria in the embodiment are met in the test in block 1420, then data may be exchanged at block 
1430. Exchanging data may include moving or copying some or all of database 1 10, database 120, and/or database 
140 between mobile device 240 and computer 210. 
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In the preferred embodiment, a Student identifier is assigned to mobile device 240, and the following data 
is copied from computer 2 1 0 to mobi le device 240: Tutor account information from database 1 1 0, content from 
database 120 that corresponds (using the procedures in FIG. 8 and FIG. 9) to the Student identifier that is assigned to 
mobile device 240. The data that may be copied or moved from mobile device 240 to computer 210 may include: the 
Student identifier assigned to mobile device 240, and Student's performance data that conforms to the format of 
database 140 (if it has been created on mobile device 240 according to the procedure in FIG. 10). 

In the preferred embodiment, the performance data (on mobile device 240) that conforms to the data 
structure in database 140 may be added to database 140 on computer 210 (via data exchange procedure 150), so that 
database 140 on computer 2 1 0, as different performance data is added to it from different mobile devices 240, 
represents a master repository of Student performance data. 

While the invention has been described in connection with a preferred embodiment, it is not intended to 
limit the scope of the invention to the particular form set forth, but on the contrary, it is intended to cover such 
alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as 
defined by the appended claims. 
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